Nowadays, complex computations are typically executed by means of a plurality of distributed computer systems which communicate over networks, such as the Internet. In such a scenario, each computer is in charge of certain functionality and the computers invoke each other's functionalities to collectively accomplish the overall computation.
One methodology for realizing such a distributed processing is called service-oriented architecture (SOA). Generally speaking, SOA comprises principles and methodologies for the design, development and operation of software as interoperable services. That is, each application running on a certain computer system registers its provided functionality as a so-called service in a central SOA registry. Other services can then query the SOA registry, retrieve an interface definition of a suitable service and invoke that service. The concept of SOA is increasingly popular due to the loose coupling between the services, which leads to computer systems which are particularly flexible to adaptations and changes. Further, a SOA allows for the interworking of heterogeneous systems, i.e. systems that are based on different software, programming languages, hardware and/or operating systems, since such heterogeneous systems are enabled to interact with one another via the well-defined interfaces registered in the SOA registry.
Those skilled in the art will appreciate that controlling the correct operation of a large SOA-based system is a complex and difficult task, while catastrophic impacts on the overall SOA system can arise already if one single service does not operate as expected. For example, consider a SOA-based system that operates an assembly line e.g. for the manufacturing of vehicles. If one service of the SOA does not operate as expected, this could lead to a complete halt of the assembly line or even to damages to the produced vehicles. Another example involves a SOA that operates an air traffic control system in an airport. If one service in the SOA does not operate as expected, this could have catastrophic consequences for the managed airport, possibly even involving plane crashes in the worst case.
Therefore, various approaches have been proposed in the prior art for controlling the correct operation of a SOA, i.e. to ensure that all participants (such as services) in the SOA operate as expected. These approaches for controlling the correct operation of a SOA are commonly referred to as “SOA governance” and include among others ensuring that all SOA components interact properly in terms of communication patterns, security rules, response times and/or other performance characteristics (quality of services), ensuring that changing a service does not impose unforeseen consequences on service consumers (change management) and/or ensuring that services evolve within the system only in a controlled manner (lifecycle management).
One way of implementing a certain subsystem of a SOA in the programming language Java is provided by a dynamic and modularized architecture model called OSGi (Open Services Gateway initiative. OSGi is a module system and service platform for the Java programming language implementing functional components (referred to as OSGi objects) in the form of bundles and services in an OSGi environment. OSGi services are Java object instances, registered into the OSGi framework. Any Java object can be registered as a service, but typically it implements a well-known interface. OSGi bundles can be used to group one or more OSGi services and are typically specified as jar components with extra manifest headers. The functional components (i.e. bundles and services) are typically managed using a service registry of the respective OSGi environment.
US patent application publication no. 2012/0036252 A1 discloses an OSGi-based heterogeneous service integrating system, which is used for publishing OSGi service endpoints to a remote registry for discovery purposes. Further, US patent application publication 2005/0154785 A1 provides a method and system of mapping at least one web service to at least one OSGi service and exposing at least one local service as at least one local web service. The document describes exposing an OSGi service as a web service to make the service consumable outside the OSGi environment.
However, while the above-discussed prior art approaches allow for making OSGi-based systems usable within a SOA, the proposed prior art systems lack the ability of efficiently and reliably controlling the correct operation of a SOA once the OSGi part has been integrated.
It is therefore the technical problem underlying certain exemplary embodiments to provide an approach for integrating at least one OSGi environment into a Service-oriented Architecture in such a manner that the correct operation of the SOA can be efficiently and reliably controlled, thereby at least partly overcoming the above explained disadvantages of the prior art.
This problem is according to one aspect of the invention solved by a method for integrating at least one Open Services Gateway initiative (OSGi) environment into a Service-oriented Architecture (SOA), wherein the OSGi environment comprises at least one OSGi object and wherein the SOA comprises a SOA registry. In the embodiment of claim 1, the method comprises the steps of:    a. publishing the at least one OSGi object to the SOA registry; wherein    b. the publishing comprises creating an SOA object in the SOA registry corresponding to the at least one OSGi object, wherein the SOA object comprises information reflecting at least one relationship of the at least one OSGi object to at least one further OSGi object within the OSGi environment.
Accordingly, the embodiment defines a method for enabling a proper exercise of control over at least one OSGi object in the OSGi environment using a SOA registry as central control component (SOA governance). To this end, the at least one OSGi environment is integrated in a SOA in that the at least one OSGi object is published to the SOA registry. Importantly, not only the OSGi object itself is published to the SOA registry, but also its relationships to other OSGi objects. Optionally, also other information, such as metadata, can be published with the OSGi object. Publishing of the OSGi object with its relationship(s) to other OSGi objects is an important prerequisite for the achievement of operational control, since it enables e.g. to perform impact analyses on the OSGi object and its relationships, i.e. analyses of how a change to the OSGi object affects the other objects.
The present method for enabling SOA governance further provides the essential capability to govern a multitude of OSGI objects in OSGi environments with one SOA registry. One central control component in huge software platforms is indispensable to reduce complexity and to keep the performance.
In one aspect of the present invention, the OSGi object comprises information indicating a lifecycle state and/or lifecycle stage of the OSGi object, and wherein the corresponding SOA object comprises information indicating a corresponding lifecycle state and/or lifecycle stage of the SOA object.
Accordingly, SOA governance in the SOA registry can be applied on the lifecycle of the OSGi object in one aspect of the invention. Examples of lifecycle states of the objects of an OSGi environment include a development state, a testing state, a preproduction state and/or a production state. The lifecycle state of the OSGi object is then mapped to the lifecycle state of the corresponding SOA object (as instance of the OSGi object) in the SOA registry. This way, the SOA registry can govern the transition of the OSGi object from one lifecycle state to another lifecycle state, i.e. a lifecycle state change of the OSGi object can be controlled e.g. by means of policies defined on transitions between lifecycles in the SOA registry. As an example of governance, installation and uninstallation of the OSGI object requires an approval in the SOA registry. Hence, one SOA registry is enabled to control the state of one or multiple OSGi objects.
In a further aspect, the OSGi object comprises information indicating a version of the OSGi object, and wherein the corresponding SOA object comprises information indicating the version of the OSGi object. Accordingly, the version of the OSGi object is mapped to the version of the corresponding SOA object in the SOA registry. For example, the uninstallation of the OSGi object with a specific version may lead to deleting the specific version of the corresponding SOA object (and only that version) in the SOA registry.
It will be appreciated that in certain exemplary embodiments only one, only a subset, or any combination of the above-explained information (relationships, lifecycle states, versions) is published into the SOA registry.
In another aspect of the present invention, the method comprises the further steps of detecting that an OSGi object has been installed in the OSGi environment, and creating a corresponding SOA object in the SOA registry. Also, the method may comprise the further steps of detecting that an OSGi object has been updated in the OSGi environment, and updating the corresponding SOA object in the SOA registry. Lastly, the method may also comprise the further steps of detecting that an OSGi object has been uninstalled in the OSGi environment, and deleting the corresponding SOA object in the SOA registry.
Accordingly, further changes, besides lifecycle and version, of the OSGi object are noticed including installation, update and uninstallation. For example whenever a new object has been installed, it is of importance that the corresponding SOA object is created in the SOA registry. Likewise when an object has been uninstalled the corresponding SOA object is deleted in the SOA registry. The adjustment of the OSGi object with the SOA object in the SOA registry is essential to assure equal states of the objects and accurate governance in the SOA registry over currently changed OSGi objects. The fine tuning of adjustment may be handled e.g. with configuration settings.
In a preferred embodiment, the above detecting steps comprise receiving an event from the OSGi environment indicating that the corresponding OSGi object has been installed, updated and/or uninstalled in the OSGi environment. Accordingly, certain exemplary embodiments passively listen for changes in the OSGi environment and synchronize such changes to the SOA registry when a corresponding event is received, which has minimal impact on the operation of the OSGi environment (as compared to actively querying the OSGi environment e.g. in regular intervals).
In yet another aspect, the method comprises the further steps of detecting that an SOA object has been created, updated and/or deleted in the SOA registry, and installing, updating and/or uninstalling a corresponding OSGi object in the OSGi environment. Accordingly, the synchronization not only takes place in the direction from the OSGi environment to the SOA registry, but also in the inverse direction, leading to a fully synchronized integration of the OSGi environment into the SOA.
In one embodiment, the detecting comprises receiving a command from the SOA registry for installing, updating and/or uninstalling the corresponding OSGi object in the OSGi environment. Accordingly, certain exemplary embodiments again passively wait for being provided with a command from the SOA registry to perform the respective action on the OSGi environment, i.e. the SOA triggers the respective action (so-called push approach from the SOA registry). Alternatively, the detecting may comprise querying the SOA registry, preferably periodically, whether an SOA object has been created, updated and/or deleted in the to SOA registry (so-called pull approach from the OSGi environment).
Generally, the at least one OSGi object may be an OSGi bundle or an OSGi service. As already explained further above, OSGi is a module system organized in functional modules in the form of OSGi services and OSGi bundles grouping OSGi services. The present method can then be applied individually on the functional modules.
Furthermore, certain exemplary embodiments also provide a computer program comprising instructions for implementing any of the above-described methods.
Certain exemplary embodiments are also directed to an integration component for integrating at least one Open Services Gateway initiative (OSGi) environment into a Service-oriented Architecture (SOA), wherein the OSGi environment comprises at least one OSGi object and wherein the SOA comprises a SOA registry, wherein the integration component comprises:    a. means for publishing the at least one OSGi object to the SOA registry; wherein    b. the means for publishing is adapted for creating an SOA object in the SOA registry corresponding to the at least one OSGi object, wherein the SOA object comprises information reflecting at least one relationship of the at least one OSGi object with at least one further OSGi object within the OSGi environment.
Accordingly, the provided integration component (hereinafter also referred to as OSGi agent; which is preferably an OSGi bundle itself) can be understood as a gateway that integrates the OSGi world and the SOA world, as explained in connection with any of the above methods. Further advantageous modifications of embodiments of the integration component of certain exemplary embodiments are defined in further dependent claims.
Lastly, certain exemplary embodiments also relate to a Service-oriented Architecture (SOA) comprising a SOA registry, at least one Open Services Gateway initiative (OSGi) environment, and an integration component as disclosed above.